Prep for PROD ECS - #16651
Conversation
akash1810
left a comment
akash1810
left a comment
There was a problem hiding this comment.
IIUC this PR, ultimately, adds a CDK snapshot test for the current state of tag-page-rendering PROD? If so, could we can make the diff smaller to make this more accessible for future travellers? For example, I don't think we need to convert from a const to a function?
🚀 Image pushed to AWS ECRImage digest: 🐛 Run the image locallyThe following can be used to run the image locally: # Refer to image using the immutable digest. Find alternatives below.
IMAGE_IDENTIFIER="@sha256:bac9ea23513b66371b80d4566d193443da5995515de5a56dc1d9379ae7e60f93"
# Refer to image using branch tag
# IMAGE_IDENTIFIER=":branch-jr-prep-for-prod-ecs"
# Refer to image using build tag
# IMAGE_IDENTIFIER=":build-30836"
# Refer to image via the GitHub commit SHA tag
# IMAGE_IDENTIFIER=":sha-7e3afab721fe3bf1730aa1fd595dd091a5b7e721"
# Set environment variables for the AWS CLI
AWS_PROFILE="<A_PROFILE_FROM_JANUS>"
AWS_DEFAULT_REGION="eu-west-1"
IMAGE_ACCOUNT_ID=$(aws ssm get-parameter --name /organisation/accounts/deployTools --query "Parameter.Value" --output text)
REGISTRY="${IMAGE_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com"
IMAGE="${REGISTRY}/guardian/dotcom-rendering${IMAGE_IDENTIFIER}"
# Login to AWS ECR https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html
aws ecr get-login-password | docker login --username AWS --password-stdin $REGISTRY
# Pull the image
docker pull $IMAGE
# Run the image. You'll likely need to set additional flags. See https://docs.docker.com/reference/cli/docker/container/run.
docker run $IMAGE |
c9a5d27 to
b06c2f1
Compare
|
I was thinking about this yesterday... this PR does 2 things:
I wonder if tweaking things slightly would tell a cleaner story? For example:
Here, the diff of PR B illustrates which parts of the infrastructure are for ECS. WDYT? |
b06c2f1 to
f4a98fc
Compare
f4a98fc to
ac283cb
Compare
| }, | ||
| }, | ||
| instanceType: InstanceType.of(InstanceClass.C8G, InstanceSize.MEDIUM), | ||
| imageIdentifier: process.env.IMAGE_DIGEST!, |
There was a problem hiding this comment.
This implementation differs from the CODE one, which defaults to DEV. Should we be consistent across both?
There was a problem hiding this comment.
I don't think so, no. I think we explicitly fail if we can't find a value.
There was a problem hiding this comment.
Ah, I think I've been misinterpreted. In this file (dotcom-rendering/cdk/bin/cdk.ts) we currently have
This style differs from this change. Could the code style of each be the same? It becomes quite confusing otherwise IMO.
I think we explicitly fail if we can't find a value.
Additionally, I don't think we will explicitly fail as is. The ! here is a non-null assertion for TypeScript; it doesn't have any runtime implication.
ac283cb to
c423b8c
Compare
c423b8c to
7e3afab
Compare
2 participants
What does this change?
This PR adds ECS capability to the PROD tag rendering nodes, and exposes the effects via testing.
Why?
How has this change been tested?
Screenshots